IBIS Macromodel Task Group Meeting date: 30 June 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis * Jared James Google: Zhiping Yang Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan Todd Bermensolo Stephen Slater Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Note: The next meeting will be on July 14th. The normally scheduled meeting for July 7th has been cancelled. ------------- Review of ARs: - Hansel to add the PAM4 sentence back to his Rx_Clock_Recovery_Mean BIRD draft. - Done. Submitted as BIRD206. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the June 23 meeting. Curtis moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: BIRD198.2: Arpad noted that the BIRD's authors had agreed to the changes proposed by ATM at last week's meeting. Randy reported that it had been submitted to the Open Forum as BIRD198.2. Randy encouraged people to review the BIRD and raise any technical questions via an email to the ATM list. Arpad said that since it had been officially submitted to the Open Forum, he would remove it from the ATM agenda. We can add it back if the Open Forum sends it back to ATM for any further technical review. Editorial Change to Rx_Clock_Recovery_Mean (BIRD206): Arpad noted that at the last meeting the group had decided this BIRD was ready to submit to the Open Forum. Randy said that he had received it from Hansel on Friday afternoon, not quite in time to be introduced at the Open Forum meeting. It is officially BIRD206 now, and Randy has asked Steve Parker (webmaster) to post it. Walter said the BIRD was an excellent clarification of the language. Arpad said he would also remove this from the ATM agenda. Supporting PI Modeling/Simulation in IBIS: Randy reported that Zhiping was unable to attend this week, and we could likely pick this topic up at the next meeting. Randy noted that Zhiping had asked if he should start writing up a BIRD based on any of his ideas. Randy and Arpad agreed that it is too early to write a BIRD, and we are better off discussing how to approach the subject. Arpad encouraged anyone with ideas on the topic to start a discussion via email to the ATM list. New Topic - Passing Pin/signal_name into an AMI model: Randy raised a topic Michael Mirmak had first brought up during the BIRD204 (clock forwarding) discussions. For IBIS AMI simulations of DDR buses, we might need a new Reserved parameter as a way of passing the signal_name or signal identity to the model. For example, if the model is dealing with different DQ to DQS delays for different DQs, this new parameter would allow the model maker to avoid having a separate AMI model for each DQ pin. Walter suggested a new Reserved parameter Signal_Name, which would be of Type Input and Format String. It would be used to pass in the signal_name of the [Pin] in the [Component]. The EDA tool would know the pin and component information and pass it into the model. Arpad asked if DLL_ID could be used for this purpose. Walter and Randy said no and thought DLL_ID's current usage wouldn't align with overloading it in this way, though Randy noted the new parameter would be defined similarly as a String Input. Arpad said he understood DLL_ID's current purpose, and wondered if it would be useful here if we need to uniquely track all 64 DQs in a simulation, for example. Randy and Walter said the need for this new parameter is only to identity the DQ signals on a given component (4-bit or 8-bit component, for example), not the overall simulation. The goal here is to let one AMI model handle all the pins on a given component. Arpad asked if refdes information would be useful. Randy said the EDA tool would handle things at that level. This new Reserved parameter would just be used to specify which of the DQs within a given component. Randy said this was envisioned for the individual DRAM level (4 bits or 8 bits). Fangyi said you'd only need the refdes if you wanted to tell the difference between different DRAMs, but if each DRAM was the same you wouldn't need that info. Fangyi and Randy agreed the AMI model wouldn't need the refdes. Fangyi said the AMI model would already know what type of signal it was handling, so perhaps we only need an index to specify which one (e.g. 0,1,2,3 for a 4bit DRAM). Randy agreed that you'd likely have separate models for DQs and DQSs, for example, so the model would know what signal type it was handling. However, he wondered if that would be the case for all technologies and said we still might want a signal name. Curtis said if the parameter only took an index, we would still have to specify the mapping so the user or EDA tool knew which index to use for a given pin being simulated. Fangyi agreed. Fangyi asked if swizzling would pose a problem, for example, if you tell the model you're signal DQ2, the model may not be able to figure out which pin that is because of swizzling. Walter summarized the fundamental problem: One has a component with a bunch of DQ pins, one or more DQS pins, and some other pins (cntrl, etc.). We want a way to tell the .dll it's working with this particular pin on this particular component. We could either do it by pin name or signal name. You have to give rules to the person writing the software. If we're using DQ3, pin 7, how do we tell the model that? That's the problem to be solved. Randy agreed and said if you give a unique identifier, probably signal name, that would be sufficient as long as it's the signal_name given in the IBIS [Component]. That's what the model should expect to be given. Walter said it could be pin name or signal name, but the nice thing about signal name is that it's the same regardless of how you number your pins. It's clear to the tool and the model. Fangyi said the two are not always the same. He said in one design you might use one pin on the component for DQ1, and in another design you might use that same pin for DQ2 (swizzling). So signal name doesn't necessarily tell you the pin. Randy said this was a good point, and you might have the same component that can be a x4 or x8 or x16. In DDR4 and DDR5 we aren't really switching the names around, but that could happen if you have mirror functions like you see on graphics devices where a command address pin becomes a different command address pin when it's mirrored. At some point you might need to give more information such as the component name. Fangyi said if we used the pin name we wouldn't have that problem, but Randy said you still want the component name because pin 'a7' might not mean much without knowing the component. Fangyi said if we're just worried about internal delay then the pin name should be enough because the model is confined to the component. Randy agreed you could create a .dll that's tied to a given component. Walter suggested we could add another Reserved parameter to pass in the [Component] name. A model that used it would be advertising that it needs the component name as well as the signal name. Randy said that would probably do it. Arpad wondered whether using the same die in different packages would need special treatment, but perhaps having the component info would solve that too. Randy agreed and said that even in mirrored cases they typically just made a unique [Component] for each of the mirrored cases (mirror function pin 0 or 1) because that setting changes all the signal names. Arpad asked if stacked dies, multiple copies of the same die, would be a problem. He said that would probably be wrapped in an EMD model. After discussion, Randy and the group decided that higher level EBD, EMD, etc., issues would not come into play. Fangyi said the dll represents what's going on inside the die, so the model only needs to know the [Component] name and nothing higher level. Randy agreed. Fangyi asked if we wanted to use signal name or pin name. His concern was that a pin can be used for one signal name in one case and another signal name in a different case. Randy said in either case the EDA tool has to read in the [Component] information and pass in the component name and pin/signal name. So the tool is passing in information from the [Component]. The model maker could deal with either. Walter said it's a bit more complicated, and signal name would make life easier for the model maker. For example, if you have 5 components that all use the same chip, the pin names might be different, but the model maker would want to just think in terms of DQ0, DQ1, DQ2, DQ3 inside the model. Randy agreed that he finds signal name more convenient. Fangyi confirmed that we are talking about the signal_names specified in the [Component], and the naming convention is therefore created by the model maker. Randy agreed. Arpad asked if this was important enough and ready to be drafted into a BIRD. Randy took an AR to start work on a BIRD and discuss it with Michael. Randy said he would post the information to the ATM email list so everyone could be involved. cancel next meeting: Walter noted that the agenda is somewhat sparse right now. He moved that we cancel the next meeting. Curtis seconded. There were no objections. Arpad cancelled the meeting scheduled for July 7th. - Curtis: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. AR: Randy to draft some ideas for the component and signal name Reserved parameters proposal and send them to the ATM list. ------------- Next meeting: 14 July 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives